home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01a.txt / 000002_icon-group-sender _Fri May 12 10:19:29 2000.msg < prev    next >
Internet Message Format  |  2002-01-03  |  5KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id KAA00987
  4.     for icon-group-addresses; Fri, 12 May 2000 10:18:52 -0700 (MST)
  5. Message-Id: <200005121718.KAA00987@baskerville.CS.Arizona.EDU>
  6. From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
  7. To: "Ray Pereda" <raypereda@hotmail.com>, <icon-group@optima.CS.Arizona.EDU>
  8. Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
  9. Date: Fri, 12 May 2000 01:14:09 -0400
  10. X-Priority: 3
  11. X-MSMail-Priority: Normal
  12. X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15. Content-Length: 4053
  16.  
  17. ----- Original Message -----
  18. From: "Ray Pereda" <raypereda@hotmail.com>
  19. To: <ian.trudel@tr.cgocable.ca>; <icon-group@optima.CS.Arizona.EDU>
  20. Sent: Tuesday, May 02, 2000 1:36 AM
  21. Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
  22.  
  23.  
  24. > Hi Ian,
  25. >
  26. > >How about investigate a "pluginizable" data type for Icon?
  27. >
  28. > The Jcon design makes it easy to add new data types.  In the
  29. object-oriented
  30. > implementation every data type is derived from a common base class that
  31. has
  32. > many useful defaults.  Go to the www.cs.arizona.edu/icon to read more
  33. about
  34. > Jcon.
  35. >
  36. > >Data type could be added to the Icon's runtime system on the fly.
  37. >
  38. > I've heard this idea mentioned before.  This would take a little bit more
  39. > thinking things through, but it would be a big win for Icon programmers.
  40.  
  41. Hello,
  42.  
  43.     I agree on this, the extra flexibility given by such system would be
  44. really interesting. It would probably also avoid multiple version, or
  45. distribution, of Icon, such as Unicon, MT Icon, etc. (Speaking of
  46. 'distroing', that's something I dislike from Linux. There is like a gazilion
  47. of distro, making the thing hard sometime..)
  48.  
  49. I've glanced the Jcon source code. Truely remarkable, adding a new data type
  50. is pretty simple. That's not so true for the original Icon system though.
  51. The main problem is the primitive data types are embedded in some
  52. switch()s', so adding a new type requires editing many files and stuff.
  53. That's error prone. However, it would certainly be possible to add a new
  54. dynamic primitive, which would allow us to add new primitives on the fly.
  55. This could also allow either statically linked (with Icon source) or
  56. dynamically linked (shared library or dynamic linked library). This special
  57. primitive could let a third party 'register' his new data type along his
  58. special functions. The primitive system would, of course, expecting some
  59. basic functions such as data convertion or Icon operators, for example. Note
  60. the dynamic primitive data type would requires us to add only one new
  61. descriptor.
  62.  
  63. But Hey, hang on a minute.. why not rewrite the whole primitive system
  64. (*giggles*) now we speaking of it! A certain system dictionary could
  65. maintain the primitive set and manage them. No need of a dynamic dictionary,
  66. I think the primitive data types should be a limited ressource anyway. A
  67. limit of 255 primitives would be just enough for a while! Anyway, we should
  68. be able to register a primitive to the system (or) primitive dictionary,
  69. along the new functions. If name spacing possible, no need to register basic
  70. functions (such as convertion), they could have standard name (such as
  71. toString, toCSet, toInteger, ..., or fromInteger, etc) or if none found, the
  72. prim's function is automatically failing. This would be also good at the
  73. source code level, each primitive could be a new C file. So, if I want to
  74. dig into CSet functionalites, I glance in primCSet.c (or whatever). Things
  75. are clear in the implementation book and the tech reports, but at the source
  76. code level, it's somehow mixed up and there is no roadmap. Erm..
  77.  
  78. There is some bad sides of this, of course, like changing the whole source
  79. is not so trivial or making primitives co-existing may be sometimes hard
  80. (hey, what happen if you add a new prim? do we have to add convertion
  81. functions to each other prims? etc)... what else.. a new C interface (for
  82. loadable C fonction) would be needed? Anyway, I'm pretty sure you can find
  83. others.
  84.  
  85. Icon implementation is not as simple as Smalltalk, for example, but it's
  86. nonetheless interesting. There is lotsa things from Smalltalk (or Squeak)
  87. that could be good in Icon without changing the whole Icon's implementation.
  88. I know the Icon project ppl seeking the stability and portability of their
  89. programming language, but I think the dynamic primitive data type system
  90. would just be awesome!! It'd certainly worth the effort.
  91.  
  92. Any thoughts?
  93.  
  94. Ok, I'm off to bed..
  95. Ian Trudel
  96.  
  97. PS: If you're curious, check out these URL (Squeak primitive stuff):
  98. http://www.create.ucsb.edu/squeak/DIYSqPrims.html
  99. http://minnow.cc.gatech.edu/squeak/464
  100.  
  101.